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Status of this Memo 


This document provides information for the Internet community. This 
memo does not specify an Internet standard of any kind. Distribution 
of this memo is unlimited. 


IESG Note: 


This memo documents a private protocol for IPv4-based flows. This 
protocol is NOT the product of an IETF working group nor is it a 
standards track document. It has not necessarily benefited from the 
widespread and in depth community review that standards track 
documents receive. 


Abstract 


The Ipsilon Flow Management Protocol (IFMP), is a protocol for 
allowing a node to instruct an adjacent node to attach a layer 2 
label to a specified IP flow. The label allows more efficient access 
to cached routing information for that flow. The label can also 
enable a node to switch further packets belonging to the specified 
flow at layer 2 rather than forwarding them at layer 3. 
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1. Introduction 


The Ipsilon Flow Management Protocol (IFMP), is a protocol for 
instructing an adjacent node to attach a layer 2 label to a specified 
IP flow. The label allows more efficient access to cached routing 
information for that flow and it allows the flow to be switched 
rather than routed in certain cases. 


If a network node’s upstream and downstream links both redirect a 
flow at the node, then the node can switch the flow at the data link 
layer rather than forwarding it at the network layer. The label 
space is managed at the downstream end of each link and redirection 
messages are sent upstream to associate a particular flow with a 
given label. Each direction of transmission on a link is treated 
separately. 


If the flow is not refreshed by the time the lifetime field in the 
redirect message expires, then the association between the flow and 
the label is discarded. A flow is refreshed by sending a redirect 
message, identical to the original, before the lifetime expires. 


Several flow types may be specified. Each flow type specifies the 
set of fields from the packet header that are used to identify a 
flow. There must be an ordering amongst the different flow types 
such that a most specific match operation may be performed. 


A particular flow is specified by a flow identifier. The flow 
identifier for that flow gives the contents of the set of fields from 
the packet header as defined for the flow type to which it belongs. 


This document specifies the IFMP protocol for IPv4 on a point-to- 
point link. The definition of labels, and the encapsulation of 
flows, are specified in a separate document for each specific data 
link technology. The specification for ATM data links is given in 
[ENCAP]. 


2. Flow Types 
A flow is a sequence of packets that are sent from a particular 
source to a particular (unicast or multicast) destination and that 


are related in terms of their routing and any logical handling policy 
they may require. 
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A flow is identified by its flow identifier. 


Several different flow types can be defined. The particular set of 
fields from the packet header used to identify a flow constitutes the 
flow type. The values of these fields, for a particular flow, 
constitutes the flow identifier for that flow. The values of these 
fields must be invariant in all packets belonging to the same flow at 
any point in the network. 


Flow types are sub- or super-sets of each other such that there is a 
clear hierarchy of flow types. This permits a most specific match 
operation to be performed. (If additional flow types are defined in 
the future that are not fully ordered then the required behavior will 
be defined.) Each flow type also specifies an encapsulation that is 
to be used after a flow of this type is redirected. The 
encapsulations for each flow type are specified in a separate 
document for each specific data link technology. The encapsulations 
for flows over ATM data links are given in [ENCAP]. 


Three flow types are defined in this version of the protocol: 
Flow Type 0 


Flow Type 0 is used to change the encapsulation of IPv4 packets 
from the default encapsulation. 


For Flow Type 0: Flow Type = 0 and Flow ID Length = 0. 
The Flow Identifier for Flow Type 0 is null (zero length). 
Flow Type 1 
Flow Type 1 is designed for protocols such as UDP and TCP in which 
the first four octets after the IPv4 header specify a Source Port 


number and a Destination Port number. 


For Flow Type 1, Flow Type = 1 and Flow ID Length = 4 (32 bit 
words). 


The format of the Flow Identifier for Flow Type 1 is: 
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0 al 2 3 

o E E e 5: 007 28 900 S ES E B67 8-90 Ie 2 34S 6 78 9.0L 
+-t-4-4-4-4-4-4F-4-4$-4-t-t-t- ttt 4-t-4-t 4a t-t tat tat-ta4t-ta+ 
|Version| IHL |Type of Service| Time to Live | Protocol | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +H 
| Source Address | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++HHHH HHH 
| Destination Address | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +H 
| Source Port | Destination Port 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 


Flow Type 2 


For Flow Type 2, Flow Type = 2 and Flow ID Length = 3 (32 bit 
words). 


The format of the Flow Identifier for Flow Type 2 is: 


0 1 2 3 
Ord 203) 405° 67. g 9.0: A 2 3 4a 67) 89 Oe 1 2 3A SO 7 8.90 OL 
+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
|Version| IHL | Reserved | Time to Live | Reserved | 
+-+-+-+-+-+-+-+-+-+-+-+- ++ 
| Source Address | 
+-+-+-+-+-+-+-+-+-+-+- +++ 
| Destination Address | 
+-+-+-+-+-+-+-+-+-+-+- ++ 


The Reserved fields are unused and should be set to zero by the 
sender and ignored by the receiver. 


3. IFMP Adjacency Protocol 


The IFMP Adjacency Protocol allows a host or router to discover the 
identity of a peer at the other end of a link. It is also used to 
synchronize state across the link, to detect when the peer at the 
other end of the link changes, and to exchange a list of IP addresses 
assigned to the link. 


3.1 Packet Format 


All IFMP messages belonging to the Adjacency Protocol must be 
encapsulated within an IPv4 packet and must be sent to the IP limited 


broadcast address (255.255.255.255). The Protocol field in the IP 
header must contain the value 101 (decimal) indicating that the IP 
packet contains an IFMP message. The Time to Live (TTL) field in the 


IP header must be set to 1. 
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All IFMP messages belonging to the adjacency protocol have the 
following structure: 


0 


1 2 3 


OA 2) 3. 490" PB 9S Od 23 AAS. 6 TB OS O22 SAPS 0 eB DO: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


=+- 


+- 


+- 


+- 


:— + — + — + — + — + — + — 


Versi 


on | Op Code | Checksum 


+-4+-4+-4+-4-4-4-4-4-4-4+-4-4-4+-4+-4+-4+-4-4+-4-4-4+-4-4-4-4-4-4-4-4-4 


Sender Instance | 


+-4-4+-4-4-4-4-4-4-4-4+-4-4+-4-4-4-4+-4-4+-4+-4-4+-4+-4-4-4-4-4-4-4-4 


+ 


+ 


Checksum 


Newman, 


Ct... via 


Peer Instance | 
taitatatatatotatatotatataotatatrtatatotatatotatataotatatct 
Peer Identity | 
taotatotatatotatatatatatotatatotatatotatatotatatatatatct 
Peer Next Sequence Number 

tata totatrtotatatrtatatrtatatotatatotatatotatatotatatct 
Reserved | Reserved Max Ack Intvl | 
tata tototatotatatotatatartatatatatatartatatotataitotatatct 
| 


Address List ; 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


— + 


The IFMP protocol version number. The current Version = 1. 


Specifies the function of the message. Four Op Codes are 
defined for the IFMP Adjacency Protocol: 


SYN: Op Code = 
SYNACK: Op Code = 
RSTACK: Op Code = 
ACK: Op Code = 


WNHR OO 


The 16-bit one’s complement of the one’s complement sum of 
a pseudo header of information from the IP header and the 
IFMP message itself. The pseudo header, conceptually 
prefixed to the IFMP message, contains the Source Address, 
the Destination Address, and the Protocol fields from the 
IPv4 header, and the total length of the IFMP message 
starting with the Version field (this is equivalent to the 
value of the Total Length field from the IPv4 header minus 
the length of the IPv4 header itself). 
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Sender Instance 
For the SYN, SYNACK, and ACK messages, is the sender’s 
instance number for the link. The receiver uses this to 
detect when the link comes back up after going down or when 
the identity of the peer at the other end of the link 
changes. The instance number is a 32 bit number that is 
guaranteed to be unique within the recent past and to 
change when the link or node comes back up after going 
down. It is used in a similar manner to the initial 
sequence number (ISN) in TCP [RFC 793]. Zero is not a 
valid instance number. For the RSTACK message the Sender 
Instance field is set to the value of the Peer Instance 
field from the incoming message that caused an RSTACK 
message to be generated. 


Peer Instance 
For the SYN, SYNACK, and ACK messages, is what the sender 
believes is the peer’s current instance number for the 
link. If the sender of the message does not know the 
peer’s current instance number for the link, the sender 
must set this field to zero. For the RSTACK message the 
Peer Instance field is set to the value of the Sender 
Instance field from the incoming message that caused an 
RSTACK message to be generated. 


Peer Identity 
For the SYN, SYNACK, and ACK messages, is the IP address of 
the peer that the sender of the message believes is at the 
other end of the link. The Peer Identity is taken from the 
Source IP Address of the IP header of a SYN or a SYNACK 
message. If the sender of the message does not know the IP 
address of the peer at the other end of the link, the 
sender must set set this field to zero. For the RSTACK 
message, the Peer Identity field is set to the value of the 
Source Address field from the IP header of the incoming 
message that caused an RSTACK message to be generated. 


Peer Next Sequence Number 
Gives the value of the peer’s Sequence Number that the 
sender of the IFMP Adjacency Protocol message expects to 
arrive in the next IFMP Redirection Protocol message. If a 
node is in the ESTAB state, and the value of the Peer Next 
Sequence Number in an incoming ACK message is greater than 
the value of the Sequence Number plus one, from the last 
IFMP Redirection Protocol message transmitted out of the 
port on which the incoming ACK message was received, the 
link should be reset. The procedure to reset the link is 
defined in section 3.2. 
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Max Ack Intvl 
Maximum Acknowledgement Interval is the maximum amount of 
time the sender of the message will wait until transmitting 
an ACK message. 


Address List 
A list of one or more IP addresses that are assigned to the 
link by the sender of the message. The list must have at 
least one entry that is identical to the Source Address in 
the IP header. The contents of this list are not used by 
the IFMP protocol but can be made available to the routing 
protocol. 


3.2 Procedure 


The IFMP Adjacency Protocol is described by the rules and state 
tables given in this section. 


The rules and state tables use the following operations: 
o The "Update Peer Verifier" operation is defined as storing the 


Sender Instance and the Source IP Address from a SYN or SYNACK 
message received from the peer on a particular port. 


o The procedure "Reset the link" is defined as: 


1. Generate a new instance number for the link 

2. Delete the peer verifier (set the stored values of Sender 
Instance and Source IP Address of the peer to zero) 

3. Set Sequence Number and Peer Next Sequence Number to zero 

4. Send a SYN message 

5. Enter the SYNSENT state 


o The state tables use the following Boolean terms and operators: 


A The Sender Instance in the incoming message matches the 
value stored from a previous message by the "Update Peer 
Verifier" operation for the port on which the incoming 
message is received. 


B The Sender Instance and the Source IP Address in the 
incoming message matches the value stored from a previous 
message by the "Update Peer Verifier" operation for the 
port on which the incoming message is received. 
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The Peer Instance and Peer Identity in the incoming message 
matches the value of the Sender Instance and the Source IP 
Address currently in use for all SYN, SYNACK, and ACK 
messages transmitted out of the port on which the incoming 
message was received. 


"&&" Represents the logical AND operation 


ms Represents the logical OR operation 


"I" Represents the logical negation (NOT) operation. 


o A timer is required for the periodic generation of SYN, SYNACK, 


and ACK messages. 


The period of the timer is unspecified but a 


value of one second is suggested. 


There are two independent events: the timer expires, and a packet 
arrives. 


Timer Expires: 


Packet Arrives: 


The processing rules for these events are: 


Reset Timer 


If 
If 
Lt 


TE 


state = SYNSENT Send SYN 
state = SYNRCVD Send SYNACK 
state = ESTAB Send ACK 


incoming message is an RSTACK 
If A && C && !SYNSENT 

Reset the link 
Else Discard the message 


Else the following State Tables. 


o State synchronization across a link is considered to be achieved 
when a node reaches the ESTAB state. 


Newman, 


et. 


al. 
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State Tables 
State: SYNSENT 
+ + 
| Condition | Action | New State | 
+ + + + 
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB | 
4+-------------------- 4----------------------- = ----- === 4+----------- + 
| SYNACK && !C | Send RSTACK | SYNSENT | 
4-------------------- 4----------------------- = === === 4+----------- + 
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD | 
4+-------------------- 4------------------------- === === 4+----------- + 
| ACK | Send RSTACK | SYNSENT | 
+ + 
State: SYNRCVD 
+ + 
| Condition | Action | New State | 
+ + + + 
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB | 
4-------------------- 4---------------------- = -- = - == === 4+----------- + 
| SYNACK && !C | Send RSTACK | SYNRCVD | 
4-------------------- 4----------------------- === === 4+----------- + 
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD | 
4-------------------- 4----------------------- = -- == === 4+----------- + 
| ACK && B &&C_ | Send ACK | ESTAB | 
4-------------------- 4----------------------- == -- = === 4+----------- + 
| ACK && !(B && C) | Send RSTACK | SYNRCVD | 
+ + 
State: ESTAB 
+ 
| Condition | Action | New State 
+ + + 
| SYN || SYNACK | Send ACK (note 1) | ESTAB 
4+--------------------- 4------------------------------ === === 4+----------- 
| ACK && B&& C | Send ACK (note 1) | ESTAB 
4--------------------- 4------------------------- = -- = === 4+----------- 
| ACK && !(B && C) | Send RSTACK | ESTAB 
+ 
Note 1: No more than one ACK should be sent within any time period of 
length defined by the timer. 
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4. IFMP Redirection Protocol 


A sender encapsulates within an IPv4 packet all IFMP messages 
belonging to the Redirection Protocol. The sender sends these 
messages to the unicast IP address of the peer at the other end of 
the link. The IP address of the peer is obtained from the adjacency 
protocol. The Protocol field in the IP header must contain the value 
101 (decimal) indicating that the IP packet contains an IFMP message. 
The Time to Live (TTL) field in the IP header must be set to 1. 


All IFMP Redirection Protocol messages have the following structure: 


0 1 2 3 
Od 23 4 O62 7 86 90) 1 A384 5 ON P28 O00 1. 2 3) 2b 6 7 82 9- Oe A 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Version | Op Code | Checksum 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Sender Instance | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Peer Instance | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Sequence Number | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


:— + — + — + — + — + 


Message Body 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Version 
The IFMP protocol version number, currently Version = 1. 
Op Code 
This field gives the message type. Five message types are 
currently defined for the IFMP Redirection Protocol: 
REDIRECT: Op Code = 4 
RECLAIM: Op Code = 5 
RECLAIM ACK: Op Code = 6 
LABEL RANGE: Op Code = 7 
ERROR: Op Code = 8 
Checksum 


The 16-bit one’s complement of the one’s complement sum of 
a pseudo header of information from the IP header, and the 
IFMP message itself. The pseudo header, conceptually 

prefixed to the IFMP message, contains the Source Address, 
the Destination Address, and the Protocol fields from the 
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IPv4 header, and the total length of the IFMP message 
starting with the version field (this is equivalent to the 
value of the Total Length field from the IPv4 header minus 
the length of the IPv4 header itself). 


Sender Instance 
The sender’s instance number for the link from the IFMP 
Adjacency Protocol. 


Peer Instance 
What the sender believes is the peer’s current instance 
number for the link from the IFMP Adjacency protocol. 


Sequence Number 
The sender must increment by one, modulo 2**32, for every 
IFMP Redirection Protocol message sent across a link. It 
allows the receiver to process IFMP Redirection Protocol 
messages in order. The Sequence Number is set to zero when 
a node resets the link. 


Message Body 
Contains a list of one or more IFMP Redirection Protocol 
message elements. All of the message elements in the list 
have the same message type because the Op Code field 
applies to the entire IFMP message. The number of message 
elements included in a single packet must not cause the 
total size of the IFMP message to exceed the MTU size of 
the underlying data link. Only a single message element is 
permitted in a Label Range message or in an Error message. 


No IFMP Redirection Protocol messages can be sent across a link until 
the IFMP Adjacency Protocol has achieved state synchronization across 
that link. All IFMP Redirection Protocol messages received on a link 
that does not currently have state synchronization must be discarded. 
For every received IFMP Redirection Protocol message the receiver 
must check the Source IP Address from the IP header, the Sender 
Instance, and the Peer Instance. The incoming message must be 
discarded if the Sender Instance and the Source IP Address fields do 
not match the values stored by the "Update Peer Verifier" operation 
of the IFMP Adjacency Protocol for the port on which the message is 
received. The incoming message must also be discarded if the Peer 
Instance field does not match the current value for the Sender 
Instance of the IFMP Adjacency Protocol. 
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4.1 Redirect Message 


The Redirect Message element is used to instruct an adjacent node to 
attach one or more given labels to packets belonging to one or more 
specified flows each for a specified period of time. The Redirect 
message is not acknowledged. 


Each Redirect message element has the following structure: 


0 1 2 3 

Oo dy 23) 4 BO B89 OL 2S 4 B62 E e 990 23s Bp 62 P89 OL: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Flow Type | Flow ID Length | Lifetime 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Label | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 


Flow Identifier 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Flow Type 
Specifies the Flow Type of the flow identifier contained in 
the Flow Identifier field. 


Flow ID Length 
Specifies the length of the Flow Identifier field in 
integer multiples of 32 bit words. 


Lifetime field 
Specifies the length of time, in seconds, for which this 
redirection is valid. The association of flow identifier 
and label should be discarded at a time no greater than 
that specified by the Lifetime field. A value of zero is 
not valid. 


Label field 
Contains a 32 bit label. The format of the label is 
dependent upon the type of physical link across which the 
Redirect message is sent. (The format of the label for ATM 
data links is specified in [ENCAP].) 


Flow Identifier 
Identifies the flow with which the specified label should 
be associated. The length of the Flow Identifier field 
must be an integer multiple of 32 bit words to preserve 32 
bit alignment. 
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A node can send an IFMP message containing one or more Redirect 
message elements across a link to its upstream neighbor. Each 
Redirect message element requests that the upstream neighbor 
associate a given link-level label to packets belonging to a 
specified flow for up to a specified period of time. A node 
receiving an IFMP message that contains one or more Redirect message 
elements from an adjacent downstream neighbor can choose to ignore 
any or all of the Redirect message elements. Neither the IFMP 
message nor any of the Redirect message elements are acknowledged. 
If the node chooses to accept a particular Redirect message element 
and to redirect the specified flow, it should attach the label 
specified in the Redirect message element to all further packets sent 
on that flow until it chooses to do so no longer, or until the 
specified lifetime expires. While the flow remains redirected, the 
encapsulation specified by the definition of the Flow Type given in 
the Redirect message element must be used for all packets belonging 
to that flow. If the label in a Redirect message element is outside 
the range that can be handled across the relevant link, a Label Range 
message can be returned to the sender. The Label Range message 
informs the sender of the Redirect message of the range of labels 
that can be sent across the link. 


If a Redirect message element is received specifying a flow that is 
already redirected, the Label field in the received Redirect message 
element must be checked against the label stored for the redirected 
flow. If they agree, the lifetime of the redirected flow is reset to 
that contained in the Redirect message element. If they disagree, 
the Redirect message element is ignored, and the flow returned to the 
default state. There is a minimum time between Redirect message 
elements specifying the same flow. The default value is one second. 


If a receiving node detects an error in any of the fields of a 
Redirect message element, the node must discard that message element 
without affecting any other Redirect message elements in the same 
IFMP message. The receiver should return an error message to the 
sender only in the case that the receiver does not understand the 
version of the IFMP protocol in the received IFMP message or does not 
understand a Flow Type in any of the Redirect message elements. An 
Error Message should be returned for each Flow Type that is not 
understood. 


4.2 Reclaim Message 
The Reclaim message element is used by a node to instruct an adjacent 


upstream node to unbind one or more flows from the labels to which 
they are currently bound, and to release the labels. 
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Each Reclaim message element has the following structure: 


0 1 2 3 
0 T-2734 BP 6: BD 0 2 3 Ae es e = 28> 29° 0 24d 3) 36: 7-829. Oh 
mt ta ttt tt titted ta titi titi ti titi ti titi HHHH 
Flow Type | Flow ID Length| Reserved 
-+-+-+-+-+-+-+-+-+-+-+-+ titi titi titi ti titi HHHH 
Label | 
-+-+-+-+-+-+-+-+-+-+-+-+-++ +++ HHHH 
| 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


:— + — + — + 


Flow Identifier 


+ — 


Flow Type 
Specifies the Flow Type of the Flow Identifier contained in 
the Flow ID field. 


Flow ID Length 
Specifies the length of the Flow Identifier field in 
integer multiples of 32 bit words. 


Reserved 
Field is unused and should be set to zero by the sender and 
ignored by the receiver. 


Label 
Field contains the label to be released. 


Flow Identifier 
Field contains the flow identifier to be unbound. 


A node can send a Reclaim message element to instruct an adjacent 
upstream node to unbind a flow from the label to which it is 
currently bound, return the flow to the default forwarding state, and 


release the label. Each Reclaim message element applies to a single 
flow and a single label. When the receiver has completed the 
operation, it must issue a Reclaim Ack message element. Reclaim Ack 


message elements can be grouped together, in any order, into one or 
more IFMP Reclaim Ack messages and returned to the sender as an 
acknowledgment that the operation is complete. 


If a Reclaim message element is received indicating an unknown flow, 


a Reclaim Ack message element must be returned containing the same 
Label and Flow Identifier fields from the Reclaim message. 
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If a Reclaim message element is received indicating a known flow, but 
with a Label that is not currently bound to that flow, the flow must 
be unbound and returned to the default forwarding state, anda 
Reclaim Ack message sent containing the actual label to which the 
flow was previously bound. 


If the receiver detects an error in any of the fields of a Reclaim 
message element, the receiver must discard that message element, 
without affecting any other Reclaim message elements in the same 
message. The receiver must return an error message to the sender 
only in the case that the receiver does not understand the version of 
the IFMP protocol in the received message or does not understand a 
Flow Type in one of the Reclaim message elements. 


4.3 Reclaim Ack Message 


The Reclaim Ack message element is used by a receiving node to 
acknowledge the successful release of one or more reclaimed labels. 


Each Reclaim Ack message element has the following structure: 


(0 I 2 3 
OUD 2: 3 AASE PB 89. 0 2. 35 45 6 E896 OL 2. BA E I 89x0] 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
Flow Type | Flow ID Length| Reserved 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
Label | 
mt tati titi ti titi ttatta titi titi tti titi titi HHHH 
| 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


:— + — +— + 


Flow Identifier 


+ — 


Flow Type 
Specifies the Flow Type of the Flow Identifier contained in 
the Flow Identifier field. 


Flow ID Length 
Specifies the length of the Flow Identifier field in 
integer multiples of 32 bit words. 


Reserved 
Field is unused and should be set to zero by the sender and 
ignored by the receiver. 


Label 


Field contains the label released from the flow specified 
by the Flow Identifier. 
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Flow Identifier 
Field contains the Flow Identifier from the Reclaim message 
element that requested the release of the label specified 
in the Label field. 


A Reclaim Ack message element must be sent in response to each 
Reclaim message element received. It is sent to indicate that the 
requested flow is now unbound and that the label is now free. If 
possible, each Reclaim Ack message element should not be sent until 
all data queued for transmission on the link, using the label 
specified for release, has been sent. 


If a Reclaim Ack message element is received specifying a flow for 
which no Reclaim message element was issued, that Reclaim Ack message 
element must be ignored, but no other Reclaim Ack message elements in 
the same message must be affected. 


If a Reclaim Ack message element is received specifying a different 
label from the one sent in the original Reclaim message element for 
that flow, the Reclaim Ack message element should be handled as if 
the reclaim operation were successful. 


If an error is detected in any of the fields of a Reclaim Ack message 
element, that message element must be discarded, but no other Reclaim 
Ack message elements in the same message must be affected. 


The receiver should return an Error message to the sender only in the 
case that the receiver does not understand the version of the IFMP 
protocol in the received message or does not understand a Flow Type 
in one of the Reclaim Ack message elements. 


4.4 Label Range Message 


The Label Range message element is sent in response to a Redirect 
message if the label requested in one or more of the Redirect message 
elements is outside the range that the receiver of the Redirect 
message can handle. The Label Range message informs the sender of 
the Redirect message of the label range that can be handled on the 
relevant link. 


Only a single Label Range message element is permitted in a Label 


Range message. The Label Range message element has the following 
structure: 
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0 1 2 3 
012-34 5°67 8 9 OL 23.4 °5-6 7-8 9 012 3.4.5 6 7 8 9-0 1 
Foto tatatataotata ta tatata ta totatatataotatatatatatatatatetatitatatat 
| Minimum Label | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +++ 
| Maximum Label | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 


Minimum Label 
The minimum value of label that can be specified in an IFMP 
Redirection Protocol message across this link. 


Maximum Label 
The maximum value of label that can be specified in an IFMP 
Redirection Protocol message across this link. 


All values of label within the range Minimum Label to Maximum Label 
inclusive may be specified in an IFMP Redirection Protocol message 
across the link. 


4.5 Error Message 


An Error message can be sent by a node in response to any IFMP 
Redirection Protocol message. 


Only a single Error message element is permitted in an Error message. 
The Error message element has the following structure: 


0 a 2 3 
O123 459 673 90 12345678901 2345 673 9 01 
tata totataHtotatartatatartotatatota tata tatato tata AE N O E E ea E A E 
| Error Code | Parameter | 
SA iSi eE A a A a T a A a A E A a A 


Error Code 
Specifies which an error has occurred. 


Each Error message can specify a single Parameter. 
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Two Error message elements are specified: 


Bad Version: 

Error Code = 1. The sender of the Error message cannot process the 
version of the IFMP protocol of the message that caused the 
error. This message must only be sent if the version of 
the message that caused the error is greater than the most 
recent version that the sender of the Error message can 
process. The parameter field of this Error message gives 
the most recent version of the IFMP protocol that the 
sender can process, right justified, with the unused most 
Significant bits of the Parameter field set to zero. 


Bad Flow Type: 


Error Code = 2. The sender of the Error message does not understand a 
Flow Type that was received in the message that caused the 
error. The Flow Type that caused the error is given in the 
parameter field, right justified, with the unused most 
Significant bits of the Parameter field set to zero. 
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